livepatch: Implement pre-|post- apply|revert hooks

livepatch: Implement pre-|post- apply|revert hooks

This is an implementation of 4 new livepatch module vetoing hooks,
that can be optionally supplied along with modules.
Hooks that currently exists in the livepatch mechanism aren't agile
enough and have various limitations:
* run only from within a quiescing zone
* cannot conditionally prevent applying or reverting
* do not have access to the module context
To address these limitations the following has been implemented:
1) pre-apply hook
  runs before the apply action is scheduled for execution. Its main
  purpose is to prevent from applying a livepatch when certain
  expected conditions aren't met or when mutating actions implemented
  in the hook fail or cannot be executed.

2) post-apply hook
  runs after the apply action has been executed and quiescing zone
  exited. Its main purpose is to provide an ability to follow-up on
  actions performed by the pre- hook, when module application was
  successful or undo certain preparation steps of the pre- hook in
  case of a failure. The success/failure error code is provided to
  the post- hooks via the rc field of the payload structure.

3) pre-revert hook
  runs before the revert action is scheduled for execution. Its main
  purpose is to prevent from reverting a livepatch when certain
  expected conditions aren't met or when mutating actions implemented
  in the hook fail or cannot be executed.

4) post-revert hook
  runs after the revert action has been executed and quiescing zone
  exited. Its main purpose is to perform cleanup of all previously
  executed mutating actions in order to restore the original system
  state from before the current module application.
  The success/failure error code is provided to the post- hooks via
  the rc field of the payload structure.

The replace action performs atomically the following actions:
- revert all applied modules
- apply a single replacement module.
With the vetoing hooks in place various inter-hook dependencies may
arise. Also, during the revert part of the operation certain vetoing
hooks may detect failing conditions that previously were satisfied.
That could in turn lead to situation when the revert part must be
rolled back with all the pre- and post- hooks re-applied, which again
can't be guaranteed to always succeed.
The simplest response to this complication is to disallow the replace
action completely on modules with vetoing hooks.

Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
Reviewed-by: Andra-Irina Paraschiv <andraprs@amazon.com>
Reviewed-by: Petre Eftime <epetre@amazon.com>
Reviewed-by: Martin Pohlack <mpohlack@amazon.de>
Reviewed-by: Norbert Manthey <nmanthey@amazon.de>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com>